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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the stage 3 specification of the Go interface. The functional requirements and the 
stage 2 specifications of the Go interface are contained in 3GPP TS 23.002 [2] and 3GPP TS 23.207 [3]. The Go 
interface is the interface between the GGSN and the PoHcy Control Function (PCF). 

The present document defines: 

the protocol to be used between PCF and GGSN over the Go interface; 

the signalling interactions to be performed between PCF and GGSN over the Go interface; 

the information to be exchanged between PCF and GGSN over the Go interface. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

Common Open Policy Service (COPS) protocol: is a simple query and response protocol that can be used to 
exchange policy information between a policy server (Policy Decision Point) and its clients (Policy Enforcement 
Points) 

Differentiated Services (DiffServ): Diffserv networks classify packets into one of a small number of aggregated flows 
or "classes", based on the DiffServ codepoint (DSCP) in the packet's IP header 

This is known as behaviour aggregate (BA) classification. At each DiffServ router, packets are subjected to a "per-hop 
behaviour" (PHB), which is invoked by the DSCP. 

Flow identifier: used for the identification of an IP flow within a media component associated with a SIP session 
For example, a single, unidirectional media component may contain one IP flow, or two IP flows in the case of an RTP 
media stream. In case of a bidirectional flow, the same flow identifier is used for both directions. A flow identifier 
consists of two parts: 1) Media component number defined in increasing order according to the sequence of the "m=" 
lines in the SDP [17], session description and 2) IP flow number defined in the order of increasing port numbers within 
each media component, see Annex C. 

Go Interface: interface between PCF and GGSN [2] 

IP Bearer Service Manager: uses standard IP mechanisms to manage the IP Bearer Service. It resides in the GGSN 
and optionally in the UE 

Media component: is a part of an SDP session description conveying information about one media stream (e.g. type, 
format, IP address, port, transport protocol, bandwidth, direction) 

The media stream described by a media component can be either bi- or unidirectional. A media stream containing an 
RTP flow may also contain an associated RTCP flow. An SDP session description can consist of more than one media 
component. A media component shall not be deleted nor its position changed within the SDP session description. A 
media component line where the port number has previously been set to may be reused for a new media component. 

Policy Control Function (PCF): is a logical policy decision element that uses standard IP mechanisms to implement 
policy in the IP media layer 

The PCF makes decisions in regard to network based IP policy using policy rules, and communicates these decisions to 
the PEP in the GGSN. 

Proxy Call Session Control Function (P-CSCF): is a network element providing session management services (e.g. 
telephony call control) 

Policy Enforcement Point (PEP): is a logical entity that enforces policy decisions made by the PCF. It resides in the 
IP BS Manager of the GGSN 

Policy Information Base (PIB): data carried by COPS-PR is a set of policy data 

The protocol assumes a named data structure, known as a Policy Information Base (PIB), to identify the type and 

purpose of solicited and unsolicited policy information that is sent from the Policy Decision Point to the Policy 

Enforcement Point for provisioning policy or sent from the Policy Enforcement Point to the Policy Decision Point as a 

notification. 

Provisioning Instance Identifier (PRID): uniquely identifies an instance of a PRC 

Resource ReSerVation Protocol (RSVP): is used by a host to request specific qualities of service from the network 

for particular application data streams or flows 

The network responds by explicitly admitting or rejecting RSVP requests. 

Translation/mapping function: provides the inter-working between the mechanisms and parameters used within the 
UMTS Bearer Service and those used within the IP Bearer Service 

UMTS Bearer Service Manager: handles resource reservation requests from the UE. It resides in the GGSN and the 
UE 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations as specified in 3GPP TR 21.905 [1] and the following 
abbreviations apply: 

COPS Common Open Policy Service protocol 

COPS-PR COPS for policy PRovisioning 

DEC COPS DECision message 

DiffServ Differentiated Services 

DRQ COPS Delete ReQuest state message 

DSCP DiffServ Code Point 

GCID GPRS Charging IDentifier 

ICID IMS Charging IDentifier 

IMS IP Multimedia core network Subsystem 

MIB Management Information Base 

PCF Policy Control Function 

P-CSCF Proxy Call Session Control Function 

PEP Policy Enforcement Point 

PHB Per Hop Behaviour 

PIB Policy Information Base 

PRC PRovisioning Class (a type of policy data) 

PRl PRovisioning Instance (an instance of a PRC) 

PRID PRovisioning Instance iDentifier 

QoS Quality of Service 

REQ COPS REQuest message 

RPT COPS RePorT state message 

RSVP resource ReSerVation Protocol 

RTCP RTP Control Protocol 

SBLP Service Based Local Policy 

SDP Session Description Protocol 

4 Go interface 

4.1 Overview 

The Go interface allows service-based local policy information to be "pushed" to or requested by the Policy 
Enforcement Point (PEP) in the GGSN from a Policy Control Function (PCF). As defined in the stage 2 specifications 
[3], this information is used by the GGSN for: 

GPRS bearer authorisation; 

Charging correlation; 

Policy based "gating" function in GGSN; 

The Go interface uses IP flow based policies. 

The Common Open Policy Service (COPS) protocol has been developed as a protocol for use between a policy server 
and a network device, as described in [7]. 

In addition, COPS for Provisioning extensions have been developed as described in [8] with [9] describing a structure 
for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy 
at that device. The model underlying this structure is one of well-defined provisioning classes and instances of these 
classes residing in a virtual information store called the Policy Information Base (PIB). 

The Go interface shall conform to the IETF COPS [7] and the extensions of COPS -PR [8]. For the purpose of 
exchanging the required specific Go information, a 3GPP Go COPS-PR Policy Information Base (PIB) is defined in the 
present document. 
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COPS Usage for Policy Provisioning (COPS-PR) is independent of the type of policy being provisioned (QoS, Security, 
etc.). In the present document, COPS-PR is used to communicate service-based local policy information between PCF 
and GGSN. COPS-PR can be extended to provide per-flow policy control along with a 3GPP Go Policy Information 
Base (PIB). The 3GPP Go PIB may inherit part of the data object definitions from other PIBs and MIBs defined in the 
IETF. 

The minimum functionalities that the Go interface shall cover are introduced below. 

1 . Media Authorisation request from GGSN: 

The GGSN receives the binding information during the activation of a (Secondary) PDP context or during the 
modification of an existing PDP context that has been previously authorized by the PCF. To authorise the 
PDP context activation, the GGSN shall send a media authorisation request to the PCF. To authorise the PDP 
context modification, the GGSN shall send a media authorisation request to the PCF when the requested QoS 
exceeds the authorised QoS or new binding information is received. 

This authorisation request shall include the following information: 

Binding information: 

The binding information is used by the GGSN to identify the correct PCF and subsequently request 
service-based local policy information from the PCF. The GGSN may receive one or more sets of the 
binding information during an activation or modification of a PDP context. Each binding information 
consists of: 

One Authorisation token; 

One or more Flow id(s) within the session. 

It is assumed that only one set of binding information is carried within a PDP context in this Release. 

2. Media authorisation decision from PCF: 

The media authorisation information sent by the PCF to the GGSN, contains at a minimum the following 
information: 

Decision on the binding information. 

The PCF shall respond with an authorisation decision for the binding information. The authorisation decision 
shall identify that the binding information is validated with an ongoing SIP session. Additionally, the PCF shall 
verify if the multiple media components are correctly assigned to the PDP Context. If validated, the PCF shall 
also communicate the following media authorisation details to the GGSN: 

- "Authorised QoS". 

This information is used by the GGSN to authorise the media resources according to the service-based 
local policy and the requested bearer QoS. 

The "Authorised QoS" for media components signalled over the Go interface is based on the SDP 
requirements signalled and agreed previously within SIP signalling for this session. 

The "Authorised QoS" specifies the maximum QoS that is authorised for a PDP context for that specific 
binding information. In case of an aggregation of multiple media components within one PDP context, the 
combination of the "Authorised QoS" information of the individual media components is provided as the 
"Authorised QoS" for the bearer. 

The "Authorised QoS" contains the following information: 

DiffServ class: 

The DiffServ class determines the highest QoS class that can be used for the media component. It is 
derived from the media type information of the SDP media description. 
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Data rate: 

The Data rate information is extracted from the SDP bandwidth parameter, more specifically the 
bandwidth value indicated by the "b=AS:" parameter. The Data rate shall include all the overhead 
coming from the IP -layer and the layers above, e.g. UDP, RTP. The Data rate shall also include the 
overhead coming from the possible usage of RTCP. The Data rate within the "Authorized QoS" 
information for the bearer is determined from the data rate values of the individual media components 
identified in the binding information. 

Packet Classifier. 

The packet classifier for media components is based on the IP-address and port number information in the 
SDP and shall allow for all IP flows associated with the SDP media component description. 

3. Charging correlation: 

The PCF shall send the ICID provided by the P-CSCF as part of the authorisation decision. The GGSN shall 
send the GCID of the PDP Context and the GGSN address to the PCF as part of the authorisation report. 

4. Approval of QoS Commit / Removal of QoS Commit / Revoke Authorisation for GPRS and IP resources: 

The PCF controls media components and may revoke resources at any time. Approval of QoS Commit / 
Removal of QoS Commit / Revoke Authorisation for GPRS and IP resources is communicated by the PCF to the 
GGSN. 

5. Indication of PDP Context Release / Modification to/from kbit/s: 

The GGSN informs the PCF of bearer changes related to the authorised resources for the IMS session in the 
following cases: 

Loss of radio contact (modification to/from kbit/s for conversational and streaming class); 

Deactivation of PDP context. 

4.2 Go reference model 

The Go interface is defined between the PCF and the GGSN [2]. 

The PCF is a logical entity of the P-CSCF (if the PCF is implemented in a separate physical node, the interface between 
the PCF and P-CSCF is not standardised). 

The P-CSCF(PCF) is in the same PLMN as the GGSN. 

The relationships between the different functional entities involved are depicted in figure 4.2. 
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NOTE: For clarity in the diagram, network elements that are not involved in service-based local policy are not 
presented here (e.g. radio network elements, SGSN, etc). 

Figure 4.2: Go interface architecture model 



4.3 Functional elements and capabilities 



4.3.1 



GGSN 



4.3.1.1 



Service-based local policy enforcement point 



The Policy Enforcement Point (PEP) is a logical entity which resides in the GGSN and communicates with the PCF 
regarding Service-based local policy (SBLP) control. Hereafter in the present document, the GGSN is assumed to 
contain the PEP implicitly unless otherwise stated. The GGSN sends requests to and receives decisions from the PCF. 
The GGSN may cache the policy decision data of the PCF decisions. This cached information may be used later for a 
local policy decision allowing the GGSN to make policy control decision about the QoS authorization for PDP context 
modifications without requiring additional interaction with the PCF. 

The following policy enforcement point functionalities for SBLP in the GGSN are identified: 

Policy based Authorisation: 

The GGSN requests authorisation information from PCF for the media components carried by a PDP context. 
The GGSN enforces the PCF decisions related to the media components carried by a PDP context. 

The GGSN shall enforce unsohcited authorisation decisions which update the QoS and packet classifiers. 

Additionally, policy-based authorisation ensures that the resources, which can be used by each particular media 
component, are within the "Authorised QoS" specified by the PCF. This information is mapped by the 
Translation/mapping function in the GGSN to give the authorised resources for GPRS bearer admission control. 

The GGSN shall also report to the PCF its success or failure in carrying out the PCF decision. 
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- Policy based gating functionality: 

Policy based gating functionality represent the control of the GGSN over the Gate Function in the user plane, i.e. 
the forwarding of IP packets associated with a media component. In the user plane, a "gate" is defined for each 
direction of a media component. The PCF provides the gate description and the commands to open or close the 
gate. The gate description is received from the PCF in the authorisation decision. The command to open or close 
the gate shall be sent either in the authorisation decision or in subsequent decisions from the PCF. 

Indication of bearer release/modification to/from kb/s 

The GGSN shall inform the PCF when the bearer changes to or from a data rate of kb/s (an indication of bearer 
loss/recovery), and at bearer release. 

Charging Correlation 

To ensure charging correlation, the PEP shall send the GCID and the GGSN address to the PCF. The PCF shall 
also send the IMS charging identifier to the GGSN. 

4.3.1 .1 .1 QoS Information processing 

The GGSN is responsible for the policy based authorisation, i.e. to ensure that the requested QoS is in-line with the 
"Authorized QoS". 

The GGSN needs the "Authorised QoS" information of the PDP context for the uplink as well as for the downlink 
direction. Therefore, the "Authorized QoS" information for the combination of all IP flows of each direction associated 
with the media component as determined by the PCF is used. 

In case of an aggregation of multiple media components within one PDP context, the "Authorised QoS" for the bearer is 
provided by the PCF as the combination of the "Authorised QoS" information of the individual media components. 

The GGSN shall perform the proper mapping between the IP QoS information and the UMTS QoS information. This 
mapping is performed by the Translation/mapping function which maps the "Authorised QoS" information for the PDP 
context into authorised UMTS QoS information. 

It is recommended that the GGSN derives the highest allowed UMTS Traffic class for the PDP context from the 
Diffserv PHB in the "Authorized QoS" according to table 4.3.1.1.1. 

Table 4.3.1.1.1 



Diffserv PHB 


Traffic Class 


Traffic Handling Priority 


EF 


Conversational 


N/A 


AF4i 


Streaming 


N/A 


AF3i 


Interactive 


1 


AF2i 


2 


AF1i 


3 


BE 


Background 


N/A 



The Data rate within the "Authorized QoS" information for the bearer is the combination of the data rate values of the 
"Authorised QoS" of the individual media components. 

In the case of real-time UMTS bearers (conversational and streaming traffic classes), the GGSN shall consider, the Data 
rate value of the "Authorized QoS" information as the maximum value of the 'Guaranteed bitrate' UMTS QoS 
parameter, whereas the 'Maximum bitrate' UMTS QoS parameter is limited by the subscriber and service specific 
setting in the HLR/HSS (SGSN) and by the capacity/capabilities/service configuration of the network (GGSN, SGSN). 
In the case of non-real-time bearers (interactive and background traffic classes) the GGSN shall consider, the Data rate 
value of the "Authorized QoS" information as the maximum value of the 'Maximum bitrate' UMTS QoS parameter. 

The UMTS BS Manager receives the authorised UMTS QoS information for the PDP context from the 
Translation/mapping function. If the requested QoS exceeds the authorised QoS, the UMTS BS Manager shall 
downgrade the requested UMTS QoS information to the authorised UMTS QoS information. 

The GGSN may store the authorized QoS for the binding information of an active PDP context in order to be able to 
make local decisions, when the UE requests for a PDP context modification. 
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4.3.1 .2 Initialisation and maintenance 

The GGSN shall comply to the procedures described in [7] for the initialisation and maintenance of the COPS protocol 
over the Go interface. 

4.3.1.3 Gate function 

The Gate Function represents a user plane function enabling or disabling the forwarding of IP packets. A gate is 
described by a set of packet classifiers that identify IP flows associated to the gate. The packet classifier includes the 
standard 5-tuple (source IP address, destination IP address, source port, destination port, protocol) explicitly describing 
a unidirectional IP flow. 

The packet classifier is received from the PCF in an authorisation decision. In the packet classifier the source IP address 
shall be taken from the SDP information if provided. Otherwise, for bi-directional flows the operator may choose to 
identify the source IP address from the 64 bit prefix of the destination IP address in order to reduce the possibilities of 
bearer misuse. If the source IP address is not identified by the SDP information and not identified by the 64 bit prefix of 
the destination IP address then the source IP address shall be wildcarded by the PCF. If the source port number is not 
identified by the SDP information then the source port number shall be wildcarded by the PCF. 

The GGSN installs the packet filter corresponding to the packet classifier. The packet classifier includes the status that 
the gate shall be set to. 

The commands to open or close the gate lead to the enabling or disabling of the passage for IP packets. If the gate is 
closed all packets of the related IP flows are dropped. If the gate is opened the packets of the related IP flows are 
allowed to be forwarded. The opening of the gate may be part of the authorisation decision event. The closing of the 
gate may be part of the revoke authorisation decision event. 

IP Packets matching a SBLP supplied filter are subject to the gate associated with that packet filter. In the uplink 
direction, IP packets which do not match any packet filter shall be silently discarded. In the downlink direction, IP 
packets which do not match any SBLP supplied filter shall be matched against TFT supplied filters. 

4.3.1.4 Void 

4.3.1.5 Binding mechanism handling 

The binding information is used by the GGSN to identify the correct PCF and subsequently request service-based local 
policy information from the PCF. The binding information associates a PDP context with one or more media 
components of an IMS session. The GGSN may receive one or more sets of the binding information during an 
activation or modification of a PDP context. Each binding information consists of an authorisation token and the flow 
identifier(s) related to the IP flows of the actual media component. If there is more than one media component to be 
transported within the PDP context the binding information includes the flow identifier(s) for the IP flows of each of the 
media components. 

The GGSN shall store the binding information and apply it to correlate events and actions between the PDP context and 
the service-based local policy. 

The GGSN shall determine the IP address of the PCF from the PCF identifier received as part of the Authorization 
Token. This identifier shall be in the format of a fully qualified domain name. 

The GGSN shall forward the binding information received from the UE to the PCF. If multiple binding information are 
received by the GGSN, it shall forward them to the PCF. If none of the tokens included in the binding information are 
of type AUTH_SESSION, or they do not contain an AUTH_ENT_ID attribute to resolve the PCF address, then the 
GGSN shall reject the PDP context activation request. The reason for the rejection is indicated to the UE with the error 
code value "Invalid binding information". The error code is transferred to the UE in the Protocol Configuration Options 
information element as defined in 3GPP TS 24.008 [12]. 

When the GGSN receives a PDP context activation/modification to an APN for which binding information is required, 
the GGSN shall reject the PDP context activation/modification request if binding information is not received. The 
reason for the rejection is indicated to the UE with the error code value "Missing binding information". The error code 
is transferred to the UE in the Protocol Configuration Options information element as defined in 3GPP TS 24.008 [12]. 

When binding information is received, the GGSN shall ignore any UE supplied TFT, and filters in that TFT shall not be 
installed in the packet processing table. 
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4.3.2 PCF 

4.3.2.1 Service-based local policy decision point 

The PCF functions as a Policy Decision Point for the service-based local policy control. The PCF makes policy 
decisions based on session and media related information obtained from the P-CSCF. The PCF shall exchange the 
decision information with the GGSN via the Go interface. 

The following policy decision point functionaUties for SBLP are identified: 

Authorisation function: 

The PCF shall be able to provide an authorisation decision upon receiving a bearer authorisation request from the 
GGSN. The PCF shall authorise the request according to the stored session and media related information received 
from the P-CSCF. 

The PCF shall use the binding information to determine the IMS session and the set of media components. Based 
on the media components, the PCF shall determine the authorised QoS, packet filters, and gate status to be applied. 
The authorised QoS specifies the maximum allowed QoS class, and the data rate for the set of media components 
identified in the binding information. 

The PCF shall be able to provide updates to the authorisation decision at session modifications which change the 
QoS and packet classifiers for PDP contexts which are already established. 

Editor's Note: a potential for theft of service scenario has been identified with the current mechanism for 

authorisation. Extensions to the authorisation mechanisms to close potential theft of service scenarios are 
currently under investigation, and will be specified when determined. 

Revoke function: 

The PCF may revoke the authorisation of resources at any time. Revoke Authorisation for GPRS and IP 
resources is communicated by the PCF to the GGSN. 

Approval of QoS Commit / Removal of QoS Commit: 

The PCF may allow or deny for the media component(s) the usage of the PDP context by controlling the 
correlated gate(s). 

The "Approval of QoS Commit" command may either be part of the authorisation decision, or the PCF may 
provide a separate decision with the "Approval of QoS Commit" command to open the gate. 

The "Removal of QoS Commit" command may either be part of the revoke authorisation decision, or the PCF 
may provide a separate decision with the "Removal of QoS Commit" command to close the gate. 

Actions due to Indication of bearer release: 

When the GGSN informs the PCF of bearer deactivation, the PCF shall remove the corresponding authorisation 
request state. Additionally, the PCF shall inform the P-CSCF about this deletion event. 

Actions due to Indication of bearer modification: 

When the PCF receives an indication of bearer modification of the maximum bitrate to or from kbits/s, the 
PCF shall inform the P-CSCF about this modification event. 

Generation of authorisation token: 

During the session set-up the PCF generates an authorisation token for the IMS session. 

Mapping SDP parameters to "Authorized QoS" parameters: 

To perform proper authorisation, the PCF shall map the necessary SDP parameters containing session and media 
related information to "Authorized QoS" parameters. 

Charging identifiers exchange: 
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The PCF shall send the ICID provided by the P-CSCF as part of the initial authorisation decision of all the bearer 
authorization requests that correspond to the respective SIP session. 

When the PCF receives the GCID together with the GGSN address from the GGSN, it shall forward this 
information to the P-CSCF to ensure charging correlation. 

4.3.2.2 Initialisation and maintenance 

The PCF shall comply to the procedures described in [7] for the initialisation and maintenance of the COPS protocol 
over the Go interface. 

4.3.2.3 Binding mechanism handling 

The binding information is used by the GGSN to identify the correct PCF and subsequently request service-based local 
policy information from the PCF. Each set of binding information consists of an authorisation token and one or more 
flow identifier(s). 

During the session set-up the PCF generates an Authorisation Token for the IMS session. The Authorisation token shall 
be sent to the P-CSCF which forwards it to the UE in the SIP signalling. The PCF shall allocate its PCF identifier as 
part of the Authorization Token. This identifier shall be in the format of a fully qualified domain name. 

The PCF receives the binding information and a Client Handle as part of a REQ from the GGSN. The PCF shall store 
the Client Handle for each media component identified by the binding information for subsequent message exchanges. 

The authorisation token is applied by the PCF to identify the IMS session. If no IMS session can be found for an 
authorisation token, or if the PCF is otherwise unable to authorise the binding information, the PCF shall send a COPS 
decision message carrying both an INSTALL and REMOVE decision. The INSTALL decision shall identify an 
authorisation failure to the GGSN, and may include further details identifying the cause. The REMOVE decision shall 
subsequently remove this state from the GGSN. For an initial authorisation, the PCF shall then initiate a remove for the 
authorisation request. 

For a valid authorisation token the flow identifier(s) is used to select the available information on the media 
component(s) of this IMS session. The PCF sends the available authorisation information on the media component(s) 
back to the GGSN. 

If the binding information consists of more than one flow identifier, the PCF shall also verify that the media 
components identified by the flow identifiers are allowed to be transferred in the same PDP context. If any of these 
media components was mandated to be carried in a separate PDP Context, the PCF shall send a COPS decision message 
carrying both an INSTALL and REMOVE decision. The INSTALL decision shall identify an authorisation failure to 
the GGSN, and may include further details identifying the cause. The REMOVE decision shall subsequently remove 
this state from the GGSN. For an initial authorisation, the PCF shall then initiate a remove for the authorisation request. 

For a valid binding information consisting of more than one flow identifier, the information sent back to the GGSN 
shall include the aggregated QoS for all the flows and a packet filter for each flow. The flow identifiers within the 
binding information can span one or more media components. 



5 Policy control procedures 

5.1 GGSN 

5.1 .1 Initial authorization at PDP context activation 

The GGSN receives binding information during the activation of a PDP context by the UE. To perform initial 
authorization at the PDP context activation the GGSN shall send an authorisation request to the PCF including the 
binding information received from the UE. 

The GGSN identifies the required PCF from the binding information. The binding information is formatted according to 
the structure of the poUcy element defined in [1 1] and shall include the AUTH_ENT_ID and the SESSIONJD 
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attributes. The GGSN checks for a Policy Element of type AUTH_SESSION ([11]) and retrieves the AUTH_ENT_ID 
attribute from this. If this is in the form of a Fully Qualified Domain Name, then this is used to identify the correct PCF. 

The GGSN authorisation request message to the PCF shall allow the GGSN to request policy information for 
authorisation of the media components carried by a PDP context identified by binding information. 

When the GGSN receives the PCF decision regarding authorisation of the media components, the GGSN shall enforce 
the policy decision. To enforce the policy decision, the GGSN shall install the packet filters received from the PCF, and 
ignore the UE supplied TFT. 

If the PCF decision information indicates that the binding information provided by the GGSN is authorised, the GGSN 
shall proceed with activation of the PDP context. The GGSN shall map the authorized QoS resources into authorized 
resources for the bearer admission control. 

To ensure charging correlation, the GGSN shall send the GCID and GGSN address information to the PCF after the 
successful establishment of the PDP context, i.e. with the report following the initial authorization decision. 

When the PCF detects that the binding information provided by the GGSN is not associated with an ongoing SIP 
session at application layer, or is otherwise unable to authorise the binding information, the GGSN will receive a COPS 
decision message from the PCF carrying both an INSTALL and REMOVE decision. The GGSN shall reject the PDP 
context activation with the error code value 'Authorization failure of the request'. The error code is transferred to the UE 
in the Protocol Configuration Options information element as defined in 3GPP TS 24.008 [12]. The GGSN shall 
subsequently remove this state according to the REMOVE decision. For an initial authorisation request, the GGSN shall 
then send a COPS Delete Request State (DRQ) message to the PCF to remove the state in the GGSN and the PCF. 

When the GGSN sends an authorization request to the PCF but the PCF does not respond with the decision message, the 
GGSN's action is according to the local policy in the GGSN. The local policy may be configured by the operator. 

If the GGSN supports a local policy decision point (LPDP) configuration it may make local policy decisions in the 
absence of the PCF. The local policy decisions may be used to accept new PDP context activations while the connection 
to the PCF is lost. The synchronization behaviour between the GGSN and the PCF is based on the local policy 
configured by operators. 

5.1 .2 Modification of previously autinorized PDP context 

The GGSN is responsible for notifying the PCF when a procedure of PDP context modification of a previously 
authorized PDP context is performed. To authorise the PDP context modification the GGSN shall send an authorisation 
request to the PCF including the binding information received from the UE in the following cases: 

Requested QoS exceeds "Authorised QoS"; 

New binding information is received. 

The GGSN on receiving the PDP context modification request from the UE will verify the authorisation. If the GGSN 
does not have sufficient information to authorize the PDP context modification request then the GGSN shall interrogate 
the PCF for modification request authorisation. 

If the requested QoS is within the already "Authorized QoS" and the binding information is not changed, the GGSN 
need not send an authorization request to the PCF. 

The GGSN is responsible for notifying to the PCF when the procedure of the PDP context modification is performed in 
the following cases: 

Requested QoS maximum bit rate is kbit/s; 

Requested QoS maximum bit rate changes from kbit/s. 

5.1 .3 Session modification initiated decision 

A session modification may occur that modifies the media components without adding or removing media lines, for 
example, a change in the bandwidth for the media line, or a change to the port number. The GGSN will receive 
unsolicited authorisation decision from the PCF due to such modifications. 
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When the GGSN receives an unsolicited authorisation decision from the PCF with updated QoS information, the GGSN 
shall update the stored authorised QoS. If the existing QoS of the PDP context exceeds the updated authorised QoS, the 
GGSN shall initiate a timer for the UE to modify the PDP context to decrease the QoS to within the authorised limit. At 
expiry of the timer, if the PDP context still exceeds the authorised QoS, the GGSN shall perform a network initiated 
PDP context modification to reduce the QoS to the authorised level. 

When the GGSN receives an unsolicited authorisation decision from the PCF, the GGSN shall also install the new set of 
packet classifiers, removing any existing packet classifiers that are not included in the new set. 

5.1 .4 PDP context deactivation 

The GGSN is responsible for notifying the PCF when a procedure of a PDP context deactivation is performed. In case 
of a PDP context deactivation, the GGSN shall inform the PCF of the bearer release related to the SIP session. 

When a revoke authorisation for the set of media components on that PDP context is performed, the GGSN receives a 
decision message from the PCF for disabling the use of the "Authorised QoS" resources and deactivation of the PDP 
context associated with the binding information. The GGSN shall disable the use of the "Authorized QoS" resources. 
The GGSN shall initiate deactivation of the PDP context used for carrying these media components, in case that the UE 
has not performed it yet. 

5.1 .5 Gate control operation 

Upon receiving a gate decision from the PCF, the GGSN shall enforce this decision on the user plane. For each gate 
contained in the gate decision the GGSN shall perform the specified command. In case of an "Approval of QoS 
Commit" command the GGSN shall open the corresponding gate. In case of a "Removal of QoS Commit" command the 
GGSN shall close the corresponding gate. 

5.1 .6 User plane operation 

The GGSN shall enforce the configuration of the policy based "gating" functionality according to additional 
authorisation information received from the PCF. 

The filter(s) and associated gate(s) are connected to the PDP contexts where SBLP applies. For each such PDP context, 
the information received in the TFT is ignored. In the downlink direction, packets are processed against each filter in 
turn until a match is found. If a match is not found, packet processing shall then continue against filters installed from 
UE supplied TFTs for PDP contexts where SBLP is not applied. If a match is found against an SBLP supplied filter, the 
packet shall be processed according to the associated gate function. If the gate is open, the packet shall be passed to the 
UE on the associated PDP context. If the gate is closed, the packet shall be silently discarded. 

In the uplink direction, packets received on a PDP context with SBLP supplied filters shall be matched against those 
filters. If a match is found, the packet shall be passed if the gate associated with that filter is open. If the gate is closed, 
or if the packet does not match any of the packet filters, the packet shall be silently discarded. 

5.2 PCF 

5.2.1 SBLP decisions 

5.2.1 .1 SBLP authorisation decision 

The information needed for the PCF to perform media authorization is passed by the P-CSCF upon receiving a SIP 
message that contains SDP. The SDP contains sufficient information about the session, such as the end-points' IP 
address and port numbers and bandwidth requirements. 

All media components in the SDP are authorised. The media components contain one or more IP flows each represented 
by a flow identifier. Cf. the definition of flow identifier in clause 3.L The P-CSCF shall send policy setup information 
to the PCF upon every SIP message that includes an SDP payload. This ensures that the PCF passes proper information 
to perform media authorization for all possible IMS session setup scenarios. The policy setup information provided by 
the P-CSCF to the PCF for each media component shall contain the following: 
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Destination IP address; 

Destination port number; 

Transport Protocol id; 

Media direction information; 

Direction of the source (originating or terminating side); 

Indication of the group that the media component belongs to; 

Editor's note: The format of this group indication in SIP/SDP is subject to CNl's decision. 

Media type information; 

Bandwidth parameter; 

Indication of forking/non-forking. 

Additionally, upon the P-CSCF receives the ICID in SIP signalling, it shall send the ICID to the PCF. 

The PCF stores the authorised policy information, and generates an Authorisation Token to identify this decision. The 
Authorisation Token is passed back to the P-CSCF for inclusion in the SIP signalling back to the UE. 

The Authorisation Token is in the form of a Session Authorisation Data Policy Element as described in [11]. The PCF 
shall include an AUTH_ENT_ID attribute containing the Fully Qualified Domain Name of the PCF and the 
SESSION_ID attribute. 

Upon receiving the bearer authorization request from the GGSN, the PCF shall authorize the request according to the 
stored service based local policy information for the session identified by the binding information in the request. 

Decision on the binding information: 

The authorisation shall contain the decision on verifying the binding information. The PCF shall identify 
whether the binding information indeed corresponds to an initiated SIP session. 

The authorization shall also contain decision on the list of flow_IDs contained in the bearer authorisation request 
sent by the GGSN representing the list of media components intended to be carried in the same PDP Context. 
This decision shall verify that these media components are indeed allowed to be carried in the same PDP 
Context. The PCF shall make this decision by comparing the list of flow_IDs contained in the bearer 
authorization request received from the GGSN to the media component grouping indication information received 
from the P-CSCF. 

In case the UE violates the IMS level indication, and attempts to set up multiple IMS media components in a 
single PDP context despite of an indication that mandated separate PDP contexts, the PCF shall enforce the 
rejection of this PDP context request by sending an INSTALL and REMOVE decision to the GGSN. 

If the binding information and the list of flow_IDs are successfully authorised (verified) as per the means 
described above, the PCF shall also communicate the authorisation details for each media component to the 
GGSN. 

The authorisation details contain the "Authorised QoS" and the packet classifier(s) of the associated IP flows. In 
case of an aggregation of multiple media components within one PDP context, the combination of the 
"Authorised QoS" information of the individual media components is provided as the "Authorised QoS". 

Based on the media direction information and the direction of the source provided by the P-CSCF, the PCF shall 
define the direction (upstream or downstream) of the "Authorised QoS" and the packet classifier(s). 

Packet classifier(s): 

The PCF shall use the destination IP address(s), destination port number(s) and transport protocol id(s) to 
formulate a packet classifier(s). 

If the source IP address, which is part of the standard 5-tuple for packet classifying, is provided by the P- 
CSCF in the SDP, then this shall be used. Based on operator policy the source IP address for bi-directional 
flows may be identified from the 64 bit prefix of the destination IP address. If the source IP address is not 
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identified by the SDP information and not identified by the 64 bit prefix of the destination IP address then the 
source IP address shall be wildcarded by the PCF. 

If the source port number, which is part of the standard 5-tuple for packet classifying, is not provided by the 
P-CSCF in the SDP then the source port number shall be wildcarded by the PCF in the packet classifier. 

The PCF shall send the destination address and the destination port number for each IP flow associated with 
the media component. 

- "Authorized QoS": 

The "Authorised QoS" information (consisting of maximum DiffServ Class and Data Rate) for a media 
component is extracted from the media type information and bandwidth parameter of the SDP. The PCF shall 
map the media type information into a DiffServ Class which is the highest class that can be used for the media. 
As an example, the audio media type shall be mapped into Expedited Forwarding PHB. 

The PCF shall extract the Data Rate value from the "b=AS" SDP parameter. The "b=AS" parameter in the SDP 
shall contain all the overhead coming from the IP-layer and the layers above, e.g. UDP, RTP. The Data Rate 
includes the overhead coming from the possible usage of RTCP. The PCF shall use this value when determining 
the data rate value applicable for the media component. 

For non-real-time bearers the Data rate value shall be considered as the maximum value of the 'Maximum bitrate' 
parameter. 

In case of an aggregation of multiple media components within one PDP context, the PCF shall provide the 
"Authorised QoS" for the bearer as the combination of the "Authorised QoS" information of the individual media 
components. The DiffServ Class in the "Authorised QoS" for the bearer shall contain the highest PHB amongst 
the ones applied for the individual media components and indicates the highest UMTS traffic class that can be 
applied to the PDP context. 

Editor's note: It shall be possible the group identifiers to restrict the individual media components carried by the 
same PDP context to have the same PHBs. 

The Data Rate of the "Authorised QoS" for the bearer shall be the sum of the Data Rate values of the individual 
media components/IP flows and it is used as the maximum Data Rate value for the PDP context. 

The PCF may include the gate enabling command as part of the authorisation decision. Alternatively, the PCF may 
provide a separate decision for opening the gate. 

The PCF shall send the IMS charging identifier provided by the P-CSCF as part of the authorisation decision to the 
GGSN. 

Upon receiving the modified SDP information from the P-CSCF, the PCF shall update the media authorization 
information for the session. The PCF may push this updated authorisation information to the GGSN. Under certain 
condition e.g. revoke of authorization, the PCF shall push the updated pohcy decision to the GGSN. 

5.2.1 .2 Session modification initiated decision 

A session modification may occur that modifies the media components without adding or removing media lines, for 
example, a change in the bandwidth for the media line, or a change to the port number. 

When there are updates to the SDP parameters for media lines which are currently authorised, the authorisation 
information (QoS, packet classifiers) may change. The updated information (QoS, packet classifiers) shall be pushed 
down to the GGSN using an unsolicited authorisation decision. 

5.2.1 .3 SBLP revoke decision 

Upon SIP session release the PCF shall send a revoke authorisation decision to the GGSN after an operator specific 
time. The revoke authorisation decision shall be sent for each handle (PDP context) related to the session as a separate 
decision to the GGSN corresponding to the previous SBLP authorisation decision. 

The timer for a pending session release shall be terminated if the PCF receives an indication on the termination of all 
PDP context(s) related to the released session. 
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Additionally, when a media component which is bound to a PDP context is removed from a SIP session and the UE has 
not performed the corresponding modification or deactivation of the PDP context within an operator specific time the 
PCF shall revoke the authorisation for the set of media components on that PDP context. 

The timer for a pending media component removal shall be terminated if the PCF receives either a new authorisation 
request with the same handle where that media component has been removed, or an indication of the termination of the 
PDP context. 

NOTE: The values of the timers for session termination and media component removal might be different, e.g. to 
allow for some more time for the required modification of the PDP context. 

5.2.1.4 SBLP gate decision 

The PCF may send a gate decision during the session set-up or whenever the status of a media component changes 
during the session (e.g. a media component is put on hold, resumed or removed). The PCF shall not send a gate decision 
to the GGSN before it has sent the initial authorisation decision. If the initial authorisation decision has already been 
sent, the PCF may send a gate decision to the GGSN to modify the status of one or several gate(s) on the user plane. 
The gate decision shall only contain the gate(s) for which the status was changed compared to the last authorisation or 
gate decision sent to the GGSN. The gate decision contains for each gate either the "Approval of QoS Commit" 
command to open the gate or the "Removal of QoS Commit" command to close the gate. 

5.2.2 Support for forking 

The PCF shall be able to handle forking when SBLP is applied. Forking can occur as specified in 3GPP TS 23.228 [4]. 
The related UE procedures are described in 3GPP TS 24.229 [14]. 

5.2.2.1 Authorization of resources for forked responses 

When a SIP session has been originated by a connected UE, the P-CSCF may receive multiple provisional responses 
due to forking before the first final answer is received. The PCF shall allocate the same authorization token to all the 
forked responses and the corresponding early dialogues. 

The UE and the P-CSCF become aware of the forking only when the second provisional response arrives. For this, and 
any subsequent provisional response, the PCF shall identify the existing authorization information for that session. The 
PCF shall authorize any additional media components and any increased QoS requirements for the previously 
authorized media components, as requested by the forked response. Thus, the QoS authorized for a media component 
shall be equal to the highest QoS requested for that media component by any of the forked responses. Authorization is 
done by the procedures for authorization request in sections 5.1.1 and 5.1.2 and SBLP decisions in section 5.2.1.1. 

Additional packet classifiers as required by the subsequent responses are sent to the GGSN by the session modification 
initiated decision specified in section 5.2.1.2. 

5.2.2.2 Updating the authorization information at the final answer 

The PCF shall keep the authorization information requested for each of the individual early dialogues till the first final 
answer is received. Then the related early dialogue is progressed to establish the final SIP session. All the other early 
dialogues are terminated. The authorization information for the SIP session is updated to match the requirements of the 
remaining early dialogue only. Several actions may be needed in the PCF: 



• 



• 



Only the packet classifiers and the QoS indicated by the first final answer shall remain authorized. This 
information shall be sent to the GGSN by the session modification initiated decision specified in section 
5.2.1.2. This should be done without delay in order to reduce the risk for initial clipping of the media stream, 
and minimising possible misuse of resources. 

The authorization for PDP contexts that were used only for the terminated early dialogues, shall be revoked as 
specified in section 5.1.4. 

The PCF shall await new authorization requests for remaining PDP contexts with updated binding information 
to remove any media components that were authorized for the terminated early dialogues only. If necessary 
(i.e. after timeout), the authorization for these PDP contexts shall be revoked as specified in section 5.2.1.3. 
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For example, assume that three forked responses for a certain media component indicate the bandwidths 10, 30 and 
20 kbps, respectively. This media component will first be authorized for 10 kbps and then upgraded to 30 kbps, 
which will be its final value for the early dialogue phase. If the first final answer corresponds to the third forked, 
provisional response, then QoS is finally downgraded to 20 kbps. 



6 Go protocol 

6.1 Protocol support 

6.1.1 TCP connection for COPS protocol 

The GGSN receives the PCF identifier received as part of the Authorization Token, during the PDP context activation 
procedure. The GGSN resolves the PCF IP address from the PCF identifier, which is in the form of a fully qualified 
domain name. 

If there is no existing TCP connection to the PCF, the GGSN shall establish a TCP connection for COPS interactions to 
the PCF. The GGSN shall use an existing TCP connection to the PCF, whenever present. 

The TCP connection between the GGSN and the PCF may be pre-established by configuring the PCF addresses on the 
GGSN. 

All communication between the GGSN and the PCFs shall use a standardised Client-Type with a corresponding 
standardised PIB, as defined in annex B. 

The validity of the PCF may be ensured either by using a private DNS for resolving the PCF IP address or by 
configuring a list of allowed PCF IP addresses on the GGSN. 



6.1.2 COPS protocol 



The Go interface allows service-based local policy and QoS inter- working information to be "pushed" to or requested 
by the GGSN from a PCF. 

The COPS protocol supports a client/server interface between the GGSN and the PCF. The Go interface shall conform 
to the IETF COPS framework as a requirement and guideline for Stage 3 work. 

The COPS protocol allows both push and pull operations. For the purpose of the initial authorisation of QoS resources 
the pull operation shall be used. Subsequently the interactions between the PCF and the GGSN may use either pull or 
push operations. 

Policy decisions may be stored by the COPS client in a local policy decision point allowing the GGSN to make 
admission control decisions without requiring additional interaction with the PCF. 

The COPS client (PEP) can request a policy decision from the PCF triggered by a QoS signalling request. One PEP 
request may be followed by one or more asynchronous PCF decisions. Each of the decisions will allow the PCF to 
notify the PEP in the GGSN whenever necessary to change earlier decisions, generate errors etc. 

Protocol stack: IP, TCP and COPS. 

6.2 Basic COPS events/messages 

The Go interface supports event triggered information transfer between the GGSN and PCF 
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6.2.1 Type of messages 



The COPS protocol supports several messages between GGSN and PCF. The message content is dependent on 
the type of COPS operation (e.g. Client-Open/Client- Accept/Client-Close, Request, Decision and Delete Request 

State). 

The Client Open, Client Accept, Client Close, Keep Alive, Synchronize State Request and Synchronize State 
Complete messages are used for setting up and maintaining the connection between the PCF and the GGSN. 

The following messages supported by the COPS layer for Go interface are used for the policy control operations: 

- Request (REQ) message from the GGSN to the PCF is used by the GGSN to request SBLP and QoS 
inter-working information. 

Decision (DEC) message from the PCF to the GGSN is a response to the Request message or an asynchronous 
notification from PCF to the GGSN whenever necessary in order to change earlier decisions, generate errors, etc. 

Report State (RPT) message from the GGSN to the PCF is used to communicate the success, failure or changes 
to the client state of the GGSN in carrying out the PCF's decision indicated in the Decision message. 

- Delete Request State (DRQ) message from the GGSN to the PCF indicates that the state identified by the client 
handle is no longer available/relevant and the corresponding state may be removed from the PCF. 



6.3 Go events/messages 



The UMTS -specific information is carried in specific COPS-PR objects, as defined in the 3GPP Go PIB that is given in 
annex B. 



6.3.1 Event descriptions 



The Go Interface uses COPS-PR [8] schematics and the 3GPP Go PIB. For COPS-PR to support the Outsourcing Model 
it is required to add a new 3GPP Go PIB with objects to: 

Describe the Triggering Event Handling. 

Describe the Outsourcing Event. 

Describe the Decision for the Outsourced Event. 

Describe the Termination of the Outsourced Event. 

Describe the resource used for the Outsourced Event. 

6.3.1 .1 Common Header, Client Type 

Client-type is UMTS Go (Client type number to be assigned through lANA). 

6.3.1.2 Context Object 

The COPS Context Object is sent in the REQ and DEC messages. This object is used to indicate the triggering event. 
C-Num = 2, C-Type = 1 

12 3 



R-Type 


M-Type 



R-Type (Request Type Flag) 
0x08 for configuration request 
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M-Type (Message Type) 

0x01 initial capability negotiation 
0x02 create event state 
0x03 update event state 
0x04 terminate event state 

6.3.1 .3 Client Specific Information (ClientSI) for outsourcing Operation 

The binding information consisting of the Authorization Token and flow identifier(s) received by the GGSN are 
encapsulated inside the Client Specific Information object of the COPS request message sent from the GGSN to the 
PCF. The PCF identifier is extracted from the token and used inside the GGSN to resolve the address of the actual PCF. 
However, from the Go message perspective, the token is treated as an opaque entity. 

6.3.1 .4 Reporting of Device Capabilities and Device Limitations 

The functionality of reporting of device capabilities and device limitations is as described in RFC 3084 [8]. In addition, 
the following shall apply. 

The configuration request message serves as a request from the GGSN to the PCF and include provisioning client 
information to provide the PCF with client-specific configuration or capability information about the GGSN. The 
capability information to be exchanged shall include the PIB objects supported by the GGSN. This information from the 
client assists the server in deciding what types of policy the GGSN can install and enforce. 

The following GGSN capabilities may be provided in the configuration request message: 

Bearer authorisation capabilities: 

The GGSN notifies the PCF that it supports bearer authorisation capabilities. The GGSN will provide the 
token(s) and media identifier(s) in the REQ for verifying the binding information and the grouping of the media 
components by the PCF. 

"Authorised QoS" capabilities: 

The GGSN notifies the PCF that it's capable to enforce the combined "Authorised QoS" for the bearer. 

Packet classifier capabilities: 

The GGSN notifies the PCF that it's capable to enforce the packet classifier for each media component direction. 

Open /close the gate capabilities: 

The GGSN informs the PCF that it's capable to enforce a separate decision on opening the gate for the authorised 
media component and it' s capable to enforce a separate decision from the PCF regarding disabling of the gate. 

Revoke media authorisation capabilities: 

The GGSN notifies the PCF that it's capable to enforce the revoke authorisation for GPRS and IP resources 
decision from the PCF. 

Charging coordination: 

The GGSN informs the PCF that it's capable to send GCID(s) and GGSN address to the PCF. 

The GGSN informs the PCF that it's capable to receive ICID(s) from the PCF. 

Indication of QoS modifications to kbit/s and from kbit/s: 

The GGSN informs the PCF that it is able to notify when the maximum bit rate for the PDP context is modified 
to kbit/s or that the maximum bit rate for the PDP context is changed from kbit/s. 

Indication of the maximum number of media authorisation sessions: 
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The GGSN may notify the PCF how many parallel media authorisation sessions can be supported. 
The PCF responds to the configuration request with an initial DEC message. 

The R-type = 0x08 for configuration request is used here and M-type = 0x01 initial capability negotiation is used here. 
The device capabilities information exchanged by the initial messages shall be stored in the PCF. 

6.3.1 .5 Initial Go Policy Provisioning 

The functionality of initial Go policy provisioning is as described in RFC 3084 [8]. In addition, the following shall 
apply: 

The DEC message is sent from the PCF to the GGSN in response to the REQ message received from the GGSN. 
The Client Handle shall be the same as that received in the corresponding REQ message. 

The DEC message is sent as an immediate response to a configuration request with the solicited message flag set 
in the COPS message header. The PCF informs the GGSN of the capabilities that it supports. The capabilities 
exchanged shall include the PIB objects supported by the PCF. The PCF shall also inform the GGSN what types 
of events shall trigger policy control requests over the Go interface. 

The R-type = 0x08 for configuration request is used here and M-type = 0x01 initial capability negotiation is used 
here. 

6.3.2 Message description 

The Go interface uses the COPS-PR protocol. 

The following messages and events are available on the Go interface: 

- Authorisation_Request (GGSN^PCF): 

This event allows the GGSN to request authorisation details from the PCF. It contains the following information: 

Client Handle; 

Binding Information. 
The R-type = 0x08 for configuration request is used here and M-type = 0x02 create event state is used here. 

- Authorisation_Decision (PCF^GGSN): 

This event provides the GGSN with the authorisation status, and relevant authorisation decision data if 
applicable. The event contains the following information: 

Client Handle (only in the initial Authorisation_Decision); 

- ICID(s); 

- Unidirectional set (this parameter shall appear once for each direction (uplink and downlink)): 

Direction indicator; 

- "Authorised QoS"; 

Gate description (this parameter shall appear once for each required gate for this direction): 

Filter Specification - The information about the authorised IP end points addresses and ports is 
detailed below. The Filter Specification parameters are: 

Source IP address; 

Destination IP address; 

Source ports; 
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Destination ports; 

- Protocol ID. 

The Source and Destination ports are described with a range consisting of a minimum and maximum 
value. If only one port is authorised, the minimum value and maximum value of the range are 
identical. 

A filter specification describing more than one IP flow shall be only used in case of identical Protocol 
IDs, IP addresses and successive port numbers (e.g. RTP and RTCP flow of a media component). 
Furthermore, the gate status of all IP flows described by this filter specification shall be identical, 
too. 

Gate status (opened/closed) 

Editor's note; The ICID issue should still be discussed in SA5. 

The R-type = 0x08 for configuration request is used here and M-type = 0x02 create event state is used here. 

- Authorisation_Failure (PCF^GGSN): 

This event provides the GGSN with an indication of an authorisation failure, and may carry additional reason 
details. The event contains the following information: 

Client Handle; 

Authorisation failure (including any provided reason information). 

The R-type = 0x08 for configuration request is used here and M-type = 0x04 terminate event state is used here. 

- Gate Decision (PCF^ GGSN) : 

The Gate Decision indicates to the GGSN the new status of the gate(s) established for a client handle (PDP 
context). The gate status indicates to the GGSN that the gate shall be opened or closed. Only the gate(s) for 
which the status is changed are indicated by this event. The event contains the following information: 

Client Handle; 

Unidirectional set (this parameter shall appear once for each direction for which gates are being updated 
(uplink and/or downlink)): 

- Direction indicator; 

Gate description (this parameter shall appear once for each gate to be modified for this direction) : 

Filter Specification - The information about the authorised IP end points addresses and ports is 
detailed below. The Filter Specification parameters are: 

Source IP address; 

Destination IP address; 

Source ports; 

- Destination ports; 

- Protocol ID. 

The Source and Destination ports are described with a range consisting of a minimum and maximum 
value. If only one port is authorised, the minimum value and maximum value of the range are 
identical. 

A filter specification describing more than one IP flow shall be only used in case of identical Protocol 
IDs, IP addresses and successive port numbers (e.g. RTP and RTCP flow of a media component). 
Furthermore, the gate status of all IP flows described by this filter specification shall be identical, 
too. 
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Gate status (opened/closed) 
NOTE: The opening of the gate may occur at the same time / be part of the authorisation decision event. 
The R-type = 0x08 for configuration request is used here and M-type = 0x03 update event state is used here. 

- Report (RPT)s (GGSN^PCF): 

Authorisation_report; Gate_report: 

The GGSN sends a COPS RPT message back to the PCF reporting that it enforced or not the 
Authorisation_Decision, or the Gate_Decision. 

The events contain the following information: 

Client Handle; 

Success / Failure. 
The Authorization_report of the initial Authorisation_Decision includes: 

- GCID; 

- GGSN address. 

Report of state changes: 

The GGSN sends the report of state change message to the PCF reporting that the maximum bit rate for the 
PDP context is modified to kbit/s or that the maximum bit rate for the PDP context is changed from 
kbit/s. 

The event contains the following information: 

- Client Handle; 

- Maximum bit rate (set to 0kbps / changed from kbps). 

- Delete request state (GGSN^PCF): 

The GGSN informs the PCF via the delete request state message, that the PDP context is deactivated and the 
request state identified by the client handle is no longer available/relevant at the GGSN, so the corresponding 
state shall also be removed at the PCF. 

The DRQ message includes the reason why the request state was deleted. 

The event contains the following information: 

Client Handle; 

Reason code: "Tear", Sub-code: deactivation of the PDP context. 

- Remove_Decision (PCF^GGSN): 

The PCF uses the Remove_Decision to inform the GGSN that the PCF revokes the authorized resources for the 
client handle (PDP context). 

The event contains the following information: 

Client Handle. 

6.4 Go data 

The detailed data description is provided in annex B. 
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6.5 Security Considerations 

The security mechanisms described in COPS [7] and COPS-PR [8] should be re-used in 3GPP. 
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Annex A: 
(Void) 
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Annex B (normative): 
SGPPGoPIB 

G03GPP-PIB PIB-DEFINITIONS ::= BEGIN 

IMPORTS 

Unsigned32, Integer32, MODULE-IDENTITY, 
MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib 

FROM COPS-PR-SPPI 
Instanceld, Prid 

FROM COPS-PR-SPPI-TC 

InetAddress, InetAddressType, 
InetAddressPref ixLength, I net Port Number 
FROM INET-ADDRESS-MIB 

DscpOrAny 

FROM DIFFSERV-DSCP-TC 



(xx) } — Go 3GPP COPS Client Type 
— XX to be assigned by lANA 



go3gppPib MODULE-IDENTITY 

SUBJECT-CATEGORIES { go3gpp 

LAST-UPDATED " 20020 80 12200Z " 
ORGANIZATION "3GPP TSG CN WG3" 
CONTACT-INFO 

"Kwok Ho Chan 

Nortel Networks 

600 Technology Park Drive 

Billerica, MA 01821 USA 

Phone: +1 978 288 8175 

Email; khchan@nortelnetworks.com 

Louis-Nicolas Hamer 
Nortel Networks 
PO Box 3511 Station C 
Ottawa, Ontario 
Canada, KlY 4H7 
Phone: +1 613 768 3409 
Email ; nhamer@nortelnetworks . com" 
DESCRIPTION 

"A PIB module containing the set of provisioning 
classes that are required for support of policies for 
3GPP's GO interface. Release 5." 
REVISION "Release 5, v.l " 
DESCRIPTION 

"This is version 1 of the 3GPP Go PIB for release 5." 



( pib XXX } 



XXX to be assigned by lANA 



— The root OID for PRCs in the 3GPP GO PIB 



go3gppCapabilityClasses OBJECT IDENTIFIER 

go3gppEventHandlerClasses OBJECT IDENTIFIER 

go3gppEventClasses OBJECT IDENTIFIER 

go3gppEventInfoClasses OBJECT IDENTIFIER 

go3gppReqInfoClasses OBJECT IDENTIFIER 

go3gppDecInfoClasses OBJECT IDENTIFIER 

go3gppReportClasses OBJECT IDENTIFIER 

go3gppConformance OBJECT IDENTIFIER 



go3gppPib 1 } 
go3gppPib 2 } 
go3gppPib 3 } 
go3gppPib 4 } 
go3gppEvent Inf oClasses 1 
go3gppEvent Inf oClasses 2 
go3gppPib 5 } 
go3gppPib 6 } 



Capability and Limitation Policy Rule Classes 



— 3GPP GO Capability Table 
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go3gppAuthReqCapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqCapEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"The 3GPP Go Authorization Request Capability PRC." 
::= { go3gppCapabilityClasses 1 } 



goSgppAuthReqCapEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqCapEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppAuthReqCap class identifies a 
specific PRC and associated attributes as supported 
by the device . " 



PIB-INDEX { go3gppAuthReqCapPrid } 

UNIQUENESS { } 

::= { goSgppAuthReqCapTable 1 } 



GoSgppAuthReqCapEntry ::= SEQUENCE { 

goSgppAuthReqCapPrid Instanceld, 

goSgppAuthReqCapBindinglnfos Unsigned32, 
go3gppAuthReqCapFlowIds Unsigned32 

} 



go3gppAuthReqCapPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the go3gppAuthReqCap class." 

::= { go3gppAuthReqCapEntry 1 } 



go3gppAuthReqCapBindingInfos OBJECT-TYPE 

SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Binding Information 
the PEP can send with each Authorization Request. 
The value of zero indicates limit is not specified." 

DEFVAL { } 

::= { go3gppAuthReqCapEntry 2 } 



go3gppAuthReqCapFlowIds OBJECT-TYPE 
SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Flow IDs the PEP can 

send with each Authorization Request. 

The value of zero indicates limit is not specified." 
DEFVAL { } 
::= { go3gppAuthReqCapEntry 3 } 



— Go 3GPP Authorization Request Decision Capabilities 



go3gppAuthReqDecCapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqDecCapEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"The 3GPP Go Authorization Request Decision Capability PRC. 
::= { go3gppCapabilityClasses 2 } 



go3gppAuthReqDecCapEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqDecCapEntry 

STATUS current 
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DESCRIPTION 

"An instance of the goSgppAuthReqDecCap class identifies a 
specific PRC and associated attributes as supported 
by the device . " 

PIB-INDEX { go3gppAuthReqDecCapPrid } 

UNIQUENESS { } 

::= { goSgppAuthReqDecCapTable 1 } 

Go3gppAuthReqDecCapEntry ::= SEQUENCE { 

go3gppAuthReqDecCapPrid Instanceld^ 

goSgppAuthReqDecCapIcids Unsigned32 

} 

goSgppAuthReqDecCapPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqDecCap class." 
::= { go3gppAuthReqDecCapEntry 1 } 

goSgppAuthReqDecCapIcids OBJECT-TYPE 
SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"Indication of the maximum number of Icid possible 

in a single Authorization Request Decision. 

The value of zero indicates limit is not specified." 
DEFVAL { } 
::= { goSgppAuthReqDecCapEntry 2 } 



— Component Limitations Table 

— This table supports the ability to export information 

— detailing provisioning class/attribute implementation limitations 

— to the policy control function. This Component Limitiations Table 

— shall be implementation dependant and does not need to be standardized. 



— 3GPP GO Event Handler Provisioning Classes 

— PRCs sent from PCF to PEP for indicating how to handle each 

— kind of event that require actions by the GO interface. 

— For 3GPP Release 5, PRCs for Event Handling of Authorization 

— Request containing Binding Information, Flow IDs, and QoS is 

— specified. 



— 3GPP GO Authorization Request Event Handler Provisioning Table 



go3gppAuthReqHandlerTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqHandlerEnt ry 

PIB-ACCESS install 

STATUS current 

DESCRIPTION 

"PRC from PCF to PEP carried by COPS DEC messages 

indicating GO actions to take at the GGSN when an Authorization 
Request Event is detected by the GGSN. An example of an 
Authorization Request Event is the receive of a PDP Context message. 

::= ( go3gppEventHandlerClasses 1 } 



go3gppAuthReqHandlerEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqHandlerEntry 

STATUS current 

DESCRIPTION 

"An instance of the go3gppAuthReqHandler class sent by the PCF to 
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the PEP what the PEP should send upon detection of an Authorization 
Request Event . " 
PIB-INDEX { goSgppAuthReqHandlerPrid } 
UNIQUENESS { goSgppAuthReqHandlerEnable, 

goSgppAuthReqHandlerBindingInf o 
} 
::= { go3gppAuthReqHandlerTable 1 } 

GoSgppAuthReqHandlerEntry ::= SEQUENCE { 

goSgppAuthReqHandlerPrid Instance Id, 

goSgppAuthReqHandlerEnable INTEGER, 

goSgppAuthReqHandlerBindingInf o UnsignedS2 
} 

goSgppAuthReqHandlerPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of this class." 
::= ( goSgppAuthReqHandlerEntry 1 } 

goSgppAuthReqHandlerEnable OBJECT-TYPE 
SYNTAX INTEGER { 

enable (1) , 
disable (2) 
} 
STATUS current 

DESCRIPTION 

"Controls the usage of SGPP Authorization Request Events 
to trigger COPS requests to PCF on the go interface." 
DEFVAL { enable } 
::= ( goSgppAuthReqHandlerEntry 2 } 

goSgppAuthReqHandlerBindinglnfo OBJECT-TYPE 
SYNTAX UnsignedS2 
STATUS current 

DESCRIPTION 

"Indication of the maximum number of Binding Information 

be associated with a each Authorizating Request. 

The value of zero indicates policy control does not impose 

any limit . " 
DEFVAL { } 
::= { goSgppAuthReqHandlerEntry S } 



— SGPP GO Event Classes 

— PRCs from PEP to PCF carried by COPS REQ messages 

— indicating the detection of specific events in the GGSN. 

— Information required for PCF to make decision on behave 

— of GGSN is also defined here to be carried by REQ messages. 



— SGPP GO Authorization Request Event Table 

goSgppAuthReqEvent Table OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqEventEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"PRC for indication of Authorization Request Event 

and its relevant information. 

Sent by PEP to PCF upon receive of an Authorization 

Request. Using COPS REQ message." 
::= { goSgppEventClasses 1 } 



goSgppAuthReqEventEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqEventEntry 
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STATUS current 

DESCRIPTION 

"An entry in the Authorization Request Event Table 
describe a single Event sent by the PEP to the PCF. 

PIB-INDEX { goSgppAuthReqEventPrid } 

UNIQUENESS { } 

::= ( goSgppAuthReqEventTable 1 } 



GoSgppAuthReqEventEntry ::= SEQUENCE { 

goSgppAuthReqEventPrid Instanceld, 
goSgppAuthReqEventBinding Infos Prid 

) 



go3gppAuthReqEventPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqEvent class." 

::= { goSgppAuthReqEventEntry 1 } 



go3gppAuthReqEventBindingInfos OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of goSgppBindinglnfo 
class instances that are associated with this 
Authorization Request Event. 

A value of zeroDotZero indicates there are no 
goSgppBindingInf o class instance associated with 
this Authorization Event." 

::= ( goSgppAuthReqEventEntry 2 } 



— 3GPP Go Event Request Info Classes 



— 3GPP GO Binding Information Table 

go3gppBindingInfoTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppBindingInf oEntry 

PIB-ACCESS notify 

STATUS current 

DESCRIPTION 

"PRC representing Binding Information. 

Sent by PEP to PCF as part of an Authorization 

Request. In a COPS REQ message." 

::= { goSgppReqInfoClasses 1 } 



goSgppBindinglnfoEntry OBJECT-TYPE 

SYNTAX GoSgppBindinglnfoEntry 

STATUS current 

DESCRIPTION 

"An entry in the Binding Information Table 

describing a single Binding Info. 

Each entry is referenced by goSgppAuthReqEventBindinglnfos 

or goSgppBindingInf oNext . " 
PIB-INDEX { goSgppBindinglnfoPrid } 
UNIQUENESS { } 
::= ( goSgppBindingInf oTable 1 } 



GoSgppBindinglnfoEntry 



SEQUENCE { 



goSgppBindinglnfoPrid 
goSgppBindingInf oToken 
goSgppBindinglnfoFlowIds 
goSgppBindingInf oNext 



Instanceld, 
OCTET STRING, 
Prid, 

Prid 



goSgppBindinglnfoPrid OBJECT-TYPE 
SYNTAX Instanceld 
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STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppBindinglnfo class." 
::= ( goSgppBindingInf oEntry 1 } 

goSgppBindinglnfoToken OBJECT-TYPE 
SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The Authorization Token associated with this 

instance of the go3gppBindingInfo class. 

Each Binding Information must have a Token." 
::= ( goSgppBindingInf oEntry 2 } 

goSgppBindingInf oFlowIds OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of Flowlds associated 

with this instance of goSgppBindinglnfo class. 

This is the anchor of a list of goSgppFlowIdEntry 

Instances . 

A value of zeroDotZero indicates an empty list which 

is an error condition." 
DEFVAL { zeroDotZero } 
::= ( goSgppBindingInf oEntry S } 

goSgppBindingInf oNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next of a list of goSgppBindinglnfo 

instances associated with an Authorization Request. 

A value of zeroDotZero indicates this is the last of 

a list of goSgppBindinglnfo instances associated with 

an Authorization Request." 
DEFVAL { zeroDotZero } 
::= { goSgppBindingInf oEntry 4 } 



— SGPP Go Authorization Request FlowID Table 

goSgppFlowIdTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppFlowIdEntry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"Represents the collection of FlowIDs . " 
::= { goSgppReqInfoClasses 2 } 



goSgppFlowIdEntry OBJECT-TYPE 

SYNTAX GoSgppFlowIdEntry 

STATUS current 

DESCRIPTION 

"Each entry describes a single FlowID." 
PIB-INDEX { goSgppFlowIdPrid } 
UNIQUENESS { } 
::= { goSgppFlowIdTable 1 } 



GoSgppFlowIdEntry ::= SEQUENCE { 

goSgppFlowIdPrid Instanceld, 

goSgppFlowIdFlowId UnsignedS2, 

goSgppFlowIdNext Prid 



goSgppFlowIdPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
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instance of the go3gppFlowId class. 
( go3gppFlowIdEntry 1 } 



go3gppFlowIdFlowId OBJECT-TYPE 
SYNTAX Unsigned32 
STATUS current 

DESCRIPTION 

"The Flowld itself." 
: := ( go3gppFlowIdEntry 2 } 



go3gppFlowIdNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next Flowld in the list associated with the 

same Binding Information of an Authorization Request. 

This points to a list of go3gppFlowIdEntry Instances. 

A value of zeroDotZero indicates end of the list." 
DEFVAL { zeroDotZero } 
::= { go3gppFlowIdEntry 3 } 



— 3GPP Go Authorization Request Decisions 

— PRCs for carrying the Event Decision send from PCF to PEP^ 

— carried by the COPS DEC message. 

— These PRCs include support for Gates/Filters, QoS, ICIDs. 



— We can define Failure Decisions by use of COPS-PR DEC message 

— containing first an install decision (with objects indicating 

— what failed and some indication to the GGSN how to react to this 

— Error Decision), and second a remove decision (for cleanup of 

— the installed Error Decision Object) . 



Failures indicated by PCF to GGSN 
Authorization Failure 



— Authorization Request Failure Decision Table 

go3gppAuthReqFailDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqFailDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"The Authorization failure Table. Indicates failures decisions to the PEP. 
::= { go3gppDecInfoClasses 1 } 



go3gppAuthReqFailDecEntry OBJECT-TYPE 

SYNTAX Go3gppAuthReqFailDecEntry 

STATUS current 

DESCRIPTION 

"Each go3gppAuthReqFailDecEntry is per request." 
FIB-INDEX { go3gppAuthReqFailDecPrid } 
UNIQUENESS { } 
::= { go3gppAuthReqFailDecTable 1 } 



Go3gppAuthReqFailDecEntry ::= SEQUENCE { 

go3gppAuthReqFailDecPrid Instanceld, 



go3gppAuthReqFailDecReason 



INTEGER 



go3gppAuthReqFailDecPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
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instance of the go3gppAuthReqFailDec class. 
{ goSgppAuthReqFailDecEntry 1 } 



goSgppAuthReqFailDecReason OBJECT-TYPE 
SYNTAX INTEGER { 



} 



noCorrespondinglmsSession (1), 
invalidBundling (2) 



current 



STATUS 
DESCRIPTION 

"Reason for Auth Request Failure Decision given by PCF: 



noCorrespondinglmsSession; No corresponding IMS Session was found 

by the PCF 

invalidBundling: In case the UE violates the IMS level indication, and 

attempts to set up multiple IMS media components in a single PDP context despite of an indication 
that mandated separate PDP contexts." 

::= ( goSgppAuthReqFailDecEntry 2 } 



— Authorization Request Decision Table 

go3gppAuthReqDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppAuthReqDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"The Authorization Request Decision Table. " 
::= { goSgppDecInfoClasses 2 } 



go3gppAuthReqDecEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqDecEntry 

STATUS current 

DESCRIPTION 

"Each go3gppAuthReqDecEntry is per Authorization Request. 
PIB-INDEX { goSgppAuthReqDecPrid } 
UNIQUENESS { } 
::= { goSgppAuthReqDecTable 1 } 



Go3gppAuthReqDecEntry ::= SEQUENCE { 

go3gppAuthReqDecPrid Instanceld, 
goSgppAuthReqDecIcids Prid, 
goSgppAuthReqDecDirDecs Prid 

} 



go3gppAuthReqDecPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqDec class." 

::= { go3gppAuthReqDecEntry 1 } 



goSgppAuthReqDecIcids OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of IcIDs associated 

with this instance of goSgppAuthReqDec class. 

There should be one IcID on this list for each Binding 

Information in the corresponding Authorization Request. 

A value of zeroDotZero indicates an empty list and there 

is no IcID change associated with this Authorization Request 

Decision . " 

DEFVAL { zeroDotZero } 

;;= ( goSgppAuthReqDecEntry 2 } 



goSgppAuthReqDecDirDecs OBJECT-TYPE 
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SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first of a list of Directional Decisions 
associated with this instance of goSgppAuthReqDec class. 
There should be at least one and at most two Directional 
Decisions per Authorization Request Decision. 
Hence a value of zeroDotZero is illegal." 

::= { goSgppAuthReqDecEntry 3 } 



3GPP Go ICID Table 

goSgppIcidTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppIcidEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"Represents the collection of ICID entries'' 
::= { goSgppDecInfoClasses 3 } 



goSgppIcidEntry OBJECT-TYPE 

SYNTAX GoSgppIcidEntry 

STATUS current 

DESCRIPTION 

"Represents the ICID Entry" 
PIB-INDEX { goSgppIcidPrid } 
UNIQUENESS { go3gppIcidValue } 
::= { goSgppIcidTable 1 } 



GoSgppIcidEntry ::= SEQUENCE { 

goSgppIcidPrid Instanceld, 

goSgppIcidValue OCTET STRING, 

goSgppIcidNext Prid 

} 



goSgppIcidPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppIcid class." 
::= { goSgppIcidEntry 1 } 



goSgppIcidValue OBJECT-TYPE 

SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The ICID itself. The syntax of this OBJECT-TYPE needs to be confirmed. 
: := ( goSgppIcidEntry 2 } 

goSgppIcidNext OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next goSgppIcidEntry of a list of IcIDs 
associated with this instance of goSgppAuthReqDec class. 
There should be one IcID on this list for each Binding 
Information in the corresponding Authorization Request. 
A value of zeroDotZero indicates the end of the list of 
IcIDs associated with an Authorization Request Decision." 

DEFVAL { zeroDotZero } 

::= { goSgppIcidEntry S } 



— SGPP Go Authorization Request Directional Decision Table 

goSgppAuthReqDirDecTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppAuthReqDirDecEnt ry 

PIB-ACCESS install 
STATUS current 
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DESCRIPTION 

"This table represents the authorization request decision for a unique direction (e.g. 
uplink and downlink) . " 

::= { goSgppDecInfoClasses 4 } 

go3gppAuthReqDirDecEntry OBJECT-TYPE 

SYNTAX GoSgppAuthReqDirDecEntry 

STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec." 
PIB-INDEX { go3gppAuthReqDirDecPrid } 
UNIQUENESS { } 
::= { goSgppAuthReqDirDecTable 1 } 

GoSgppAuthReqDirDecEntry ::= SEQUENCE { 

goSgppAuthReqDirDecPrid Instanceld, 

goSgppAuthReqDirDecDirection INTEGER, 

goSgppAuthReqDirDecQos Prid, 

goSgppAuthReqDirDecGates Prid, 

goSgppAuthReqDirDecNext Prid 
} 

go3gppAuthReqDirDecPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgppAuthReqDirDec class." 
::= { go3gppAuthReqDirDecEntry 1 } 

goSgppAuthReqDirDecDirection OBJECT-TYPE 
SYNTAX INTEGER { 

uplink ( 1 ) , 
downlink (2) 
} 
STATUS current 

DESCRIPTION 

"Indicates the direction this decision applies to." 
::= ( goSgppAuthReqDirDecEntry 2 } 

go3gppAuthReqDirDecQos OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

" The Authorized QoS. References the go3gppQos class." 
::= ( goSgppAuthReqDirDecEntry 3 } 

goSgppAuthReqDirDecGates OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first instance of a list of the go3gppGate class." 
::= ( goSgppAuthReqDirDecEntry 4 } 

goSgppAuthReqDirDecNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next instance of a list of 
goSgppAuthReqDirDec class." 
::= { goSgppAuthReqDirDecEntry 5 } 



— SGPP Go QoS Table 

goSgppQosTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppQosEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 
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"This table represents the Authorised QoS. It is referenced by the goSgppAuthReqDirDecQos 
entry of the goSgppAuthReqDirDecEntry class." 
::= { goSgppDecInfoClasses 5 } 

go3gppQosEntry OBJECT-TYPE 

SYNTAX Go3gppQosEntry 

STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec." 
PIB-INDEX { go3gppQosPrid } 
UNIQUENESS { } 
::= { goSgppQosTable 1 } 



Go3gppQosEntry ::= SEQUENCE { 

goSgppQosPrid Instanceld, 

goSgppQosServiceClass DscpOrAny, 

goSgppQosDataRateUnit INTEGER, 

go3gppQosDataRate Unsigned32 

} 



go3gppQosPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppQos class." 
::= { goSgppQosEntry 1 } 



go3gppQosServiceClass OBJECT-TYPE 
SYNTAX DscpOrAny 

STATUS current 

DESCRIPTION 

"A Service Class Indication using DSCP Encoding." 
::= { goSgppQosEntry 2 } 



go3gppQosDataRateUnit OBJECT-TYPE 
SYNTAX INTEGER { 

bps (1), 
kbps (2), 
Mbps (3) 
} 
STATUS current 

DESCRIPTION 

"Indication of the unit of measure for go3gppQosDataRate . 
::= { go3gppQosEntry 3 } 



go3gppQosDataRate OBJECT-TYPE 
SYNTAX Unsigned32 

STATUS current 

DESCRIPTION 

"The Data Rate with unit of measure indicated by 

go3gppQosDataRateUnit . " 
::= { go3gppQosEntry 4 } 



— 3GPP Go Gate Decision Table 



There could be one of these per direction per GateDec. 

This is for changing Gating Status only when used alone 
(not as part of Direction Decision) . 

go3gppGateDec is sent in a different COPS DEC message 
from the DEC message carrying go3gppAuthReqDec . PCF must 
have sent a go3gppAuthReqDec before using go3gppGateDec . 

go3gppGateDecTable OBJECT-TYPE 
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SYNTAX SEQUENCE OF GoSgppGateDecEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"This table represents an updated gating decision. 
::= { goSgppDecInfoClasses 6 } 



go3gppGateDecEntry OBJECT-TYPE 

SYNTAX Go3gppGateDecEntry 

STATUS current 

DESCRIPTION 

"There should be one of these per direction per AuthReqDec." 
PIB-INDEX { go3gppGateDecPrid } 
UNIQUENESS { } 
::= { goSgppGateDecTable 1 } 



GoSgppGateDecEntry 



SEQUENCE 



goSgppGateDecPrid Instanceld, 

goSgppGateDecDirection INTEGER, 

goSgppGateDecGates Prid, 

goSgppGateDecNext Prid 



go3gppGateDecPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppGateDec class." 
::= { goSgppGateDecEntry 1 } 



goSgppGateDecDirection OBJECT-TYPE 
SYNTAX INTEGER { 

uplink ( 1 ) , 
downlink (2) 
} 
STATUS current 

DESCRIPTION 

"References the gate direction." 
::= { goSgppGateDecEntry 2 } 

goSgppGateDecGates OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the first instance of a list of goSgppGate class." 
::= { goSgppGateDecEntry S } 



goSgppGateDecNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References the next instance of a list of goSgppGateDec class. 
::= { goSgppGateDecEntry 4 } 



— SGPP Go Gate Table 

goSgppGateTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppGateEnt ry 

PIB-ACCESS install 
STATUS current 

DESCRIPTION 

"PRC representing a Gate." 
::= { goSgppDecInfoClasses 7 } 



goSgppGateEntry OBJECT-TYPE 
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SYNTAX Go3gppGateEntry 
STATUS current 

DESCRIPTION 

"Each instance represents one Gate. 
PIB-INDEX { go3gppGatePrid } 
UNIQUENESS { } 
::= { go3gppGateTable 1 } 



GoSgppGateEntry ::= SEQUENCE 
goSgppGatePrid 
goSgppGateFilter 
goSgppGateStatus 
goSgppGateNext 

} 



Instanceld, 
Prid, 
INTEGER, 
Prid 



go3gppGatePrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgppGate class." 
::= { goSgppGateEntry 1 } 



go3gppGateFilter OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"References an instance of the goSgppIpFilter class. 

A value of zeroDotZero indicates no goSgppIpFilter is 

used with this goSgppGate." 
::= { goSgppGateEntry 2 } 



go3gppGateStatus OBJECT-TYPE 
SYNTAX 



INTEGER { 

close (1) , 
open (2) 



STATUS current 

DESCRIPTION 

"Indicates if this gate will allow traffic to flow." 
DEFVAL { close } 

::= { goSgppGateEntry 3 } 



goSgppGateNext OBJECT-TYPE 
SYNTAX Prid 

STATUS current 

DESCRIPTION 

"Reference the next Gate on a list of goSgppGate instances. 

A value of zeroDotZero indicates this is the last Gate 

on the list . " 
::= { goSgppGateEntry 4 } 



— The Base Filter Table 



goSgppBaseFilterTable OBJECT-TYPE 



SYNTAX 
PIB-ACCESS 
STATUS 
DESCRIPTION 



SEQUENCE OF GoSgppBaseFilterEnt ry 

install 

current 



"The Base Filter class. A packet has to match all 

fields in an Filter. Wildcards may be specified for those 

fields that are not relevant . " 
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{ go3gppDecInfoClasses 



Go3gppBaseFilterEntry OBJECT-TYPE 

SYNTAX goSgppBaseFilterEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppBaseFilter class." 

PIB-INDEX { go3gppBaseFilterPrid } 

UNIQUENESS { } ::= { go3gppBaseFilterTable 1 

go3gppBaseFilterEntry ::= SEQUENCE { 

goSgppBaseFilterPrid Instanceld 



goSgppBaseFilterPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An integer index to uniquely identify this Filter among all 
the Filters . " 

::= { goSgppBaseFilterEntry 1 } 



The Go 3GPP IP Filter Table 



go3gppIpFilterTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppIpFilterEnt ry 

PIB-ACCESS install 

STATUS current 

DESCRIPTION 

"Filter definitions. A packet has to match all fields in 
filter. Wildcards may be specified for those fields that 
are not relevant . " 

::= { goSgppDecInfoClasses 9 } 

go3gppIpFilterEntry OBJECT-TYPE 

SYNTAX GoSgppIpFilterEntry 

STATUS current 

DESCRIPTION 

"An instance of the goSgppIpFilter class." 

EXTENDS { goSgppBaseFilterEntry } 
UNIQUENESS { 

goSgppIpFilterAddrType, 

goSgppIpFilterDstAddr, 

goSgppIpFilterDstPref ixLength, 

goSgppIpFilterSrcAddr, 

goSgppIpFilterSrcPref ixLength, 

goSgppIpFilterProtocol, 

go3gppIpFilterDstL4PortMin, 

go3gppIpFilterDstL4PortMax, 

go3gppIpFilterSrcL4PortMin, 

go3gppIpFilterSrcL4PortMax } 



{ go3gppIpFilterTable 1 } 



Go3gppIpFilterEntry ::= SEQUENCE { 
go3gppIpFilterAddrType 
go3gppIpFilterDstAddr 
go3gppIpFilterDstPref ixLength 
go3gppIpFilterSrcAddr 
go3gppIpFilterSrcPref ixLength 
go3gppIpFilterProtocol 
go3gppIpFilterDstL4PortMin 
go3gppIpFilterDstL4PortMax 
go3gppIpFilterSrcL4PortMin 
go3gppIpFilterSrcL4PortMax 

} 



InetAddressType, 

InetAddress, 

InetAddressPref ixLength, 

InetAddress, 

InetAddressPref ixLength, 

Integer32, 

I net Port Number, 

I net Port Number, 

I net Port Number, 

I net Port Number 
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go3gppIpFilterAddrType OBJECT-TYPE 

SYNTAX InetAddressType 

STATUS current 

DESCRIPTION 

"The address type enumeration value [INETADDR] to specify 
the type of the packet's IP address." 

::= ( go3gppIpFilterEntry 1 } 

go3gppIpFilterDstAddr OBJECT-TYPE 

SYNTAX InetAddress 

STATUS current 

DESCRIPTION 

"The IP address [INETADDR] to match against the packet's 
destination IP address. goSgppIpFilterDstPref ixLength 
indicates the number of bits that are relevant. " 

::= ( goSgppIpFilterEntry 2 } 



go3gppIpFilterDstPref ixLength OBJECT-TYPE 

SYNTAX InetAddressPrefixLength 

STATUS current 

DESCRIPTION 

"The length of a mask for the matching of the destination 
IP address. Masks are constructed by setting bits in 
sequence from the most-significant bit downwards for 
goSgppIpFilterDstPref ixLength bits length. All other bits in 
the mask, up to the number needed to fill the length of 
the address goSgppIpFilterDstAddr are cleared to zero. A zero 
bit in the mask then means that the corresponding bit in 
the address always matches." 

::= { goSgppIpFilterEntry S } 



goSgppIpFilterSrcAddr OBJECT-TYPE 
SYNTAX InetAddress 

STATUS current 

DESCRIPTION 

"The IP address to match against the packet's source IP 
address. goSgppIpFilterSrcPref ixLength indicates the 
number of bits that are relevant. " 

::= ( goSgppIpFilterEntry 4 } 

goSgppIpFilterSrcPref ixLength OBJECT-TYPE 
SYNTAX InetAddressPrefixLength 

UNITS "bits" 

STATUS current 



DESCRIPTION 

"The length of a mask for the matching of the source IP 
address. Masks are constructed by setting bits in sequence 
from the most-significant bit downwards for 

goSgppIpFilterSrcPref ixLength bits length. All other bits in 
the mask, up to the number needed to fill the length of 
the address goSgppIpFilterSrcAddr are cleared to zero. A 
zero bit in the mask then means that the corresponding bit 
in the address always matches." 

::= { goSgppIpFilterEntry 5 } 

goSgppIpFilterProtocol OBJECT-TYPE 

SYNTAX IntegerS2 (-1 | 0..255) 

STATUS current 

DESCRIPTION 

"The IP protocol to match against the packet's protocol. 
A value of -1 means match all." 

::= ( goSgppIpFilterEntry 6 } 
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go3gppIpFilterDstL4PortMin OBJECT-TYPE 

SYNTAX InetPortNumber 

STATUS current 

DESCRIPTION 

"The minimum value that the packet's layer 4 destination 
port number can have and match this filter. This value must 
be equal to or lesser that the value specified for this 
filter in go3gppIpFilterDstL4PortMax. " 

::= ( goSgppIpFilterEntry 7 } 



go3gppIpFilterDstL4PortMax OBJECT-TYPE 
SYNTAX InetPortNumber 



STATUS current 

DESCRIPTION 

"The maximum value that the packet's layer 4 destination 
port number can have and match this filter. This value must 
be equal to or greater that the value specified for this 
filter in go3gppIpFilterDstL4PortMin. " 



( goSgppIpFilterEntry 



go3gppIpFilterSrcL4PortMin OBJECT-TYPE 

SYNTAX InetPortNumber 

STATUS current 

DESCRIPTION 

"The minimum value that the packet's layer 4 source port 
number can have and match this filter. This value must 
be equal to or lesser that the value specified for this 
filter in go3gppIpFilterSrcL4PortMax. " 



goSgppIpFilterEntry 



go3gppIpFilterSrcL4PortMax OBJECT-TYPE 

SYNTAX InetPortNumber 

STATUS current 

DESCRIPTION 

"The maximum value that the packet's layer 4 source port 
number can have and match this filter. This value must be 
equal to or greater that the value specified for this filter 
in go3gppIpFilterSrcL4PortMin . " 



( goSgppIpFilterEntry 10 } 



— 3GPP Go Reports 

— PRCs for carrying the Decision enforcement result sent from PEP to PCF, 

— carried using the COPS REPORT message. 

— These PRCs include support for the success or failure of the PEP in 

— carrying out the PCF ' s decision or -change of the state in the GGSN. 

go3gppReportTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppReportEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"This table represents the success or failure of the decision enforcement and 

state changes in the PEP . " 
::= { go3gppReportClasses 1 } 

go3gppReportEntry OBJECT-TYPE 
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SYNTAX 
STATUS 
DESCRIPTION 



go3gppReport Entry 
current 



PIB-INDEX { go3gppReportPrid 

UNIQUENESS { } 

::= { go3gppReportTable 1 } 



goSgppReportEntry ::= SEQUENCE { 

goSgppReportPrid Instanceld, 
goSgppReportStatus INTEGER, 
go3gppReportDetails Prid } 



go3gppReportPrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the go3gpgReport class." 

::= { goSgppReportEntry 1 } 



go3gppReportStatus OBJECT-TYPE 
SYNTAX INTEGER { 

success (1) , 
failure (2 ) , 
usage (3) } 
STATUS current 

DESCRIPTION 

"When Status is: 

success: Indicates the successful implementation of the 
decision. 
go3gppReportDetails : 

Reference an instance of go3gppRprtGPRSChrgInfo 
for initial authorization request decision; 
References nothing otherwise (contains the value 
zeroDotZero) . 

Failure: Indicates the failure of implementing the decision. 

go3gppReportDetails may references an Error object, 
or may have the value zeroDotZero when no error 

object is needed, in which case COPS and COPS-PR 
error codes and error objects are sufficient. 
Usage: go3gppReportDetails references an instance of 
go3gppRprtUsage class." 

::= { go3gppReportEntry 2 } 



go3gppReportDetails OBJECT-TYPE 

SYNTAX Prid 

STATUS current 

DESCRIPTION 

"May reference an instance of go3gppRprtGPRSChrgInfo, 
go3gppRprtError (not defined), or go3gppRprtUsage class, 
or may have the value of zeroDotZero depending on the value of 
go3gppReportStatus . " 

::= { go3gppReportEntry 3 } 



go3gppRprtGPRSChrgInfoTable OBJECT-TYPE 

SYNTAX SEQUENCE OF Go3gppRprtGPRSChrgInf oEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 

"This table represents the GPRS Charging information" 
::= { go3gppReportClasses 2 } 



go3gppRprtGPRSChrgInfoEntry OBJECT-TYPE 

SYNTAX go3gppRprtGPRSChrgInfoEntry 

STATUS current 

DESCRIPTION 

"This entry represents the GPRS Charging Identifier and GGSN address. 
PIB-INDEX { go3gppRprtGPRSChrgInfoPrid } 
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UNIQUENESS { go3gppRprtGPRSChrgInf oGGSNAddr , 

go3gppRprtGPRSChrgInfoGCID } 
::= { go3gppRprtGPRSChrgInfoTable 1 } 



goSgppRprtGPRSChrglnfoEntry ::= SEQUENCE { 

goSgppRprtGPRSChrglnfoPrid Instance Id, 

goSgppRprtGPRSChrgInf oGGSNAddr Inet Address, 
goSgppRprtGPRSChrglnfoGCID OCTET STRING 



goSgppRprtGPRSChrglnfoPrid OBJECT-TYPE 

SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 
instance of the goSgpgRprtGPRSChrglnfo class." 
::= { goSgppRprtGPRSChrgInf oEntry 1 } 



goSgppRprtGPRSChrgInf oGGSNAddr OBJECT-TYPE 
SYNTAX InetAddress 

STATUS current 

DESCRIPTION 

"Contains the IP Address of the GGSN providing the GCID 
upon successful handling of an Authorization Request." 
::= { goSgppRprtGPRSChrgInf oEntry 2 } 



goSgppRprtGPRSChrglnfoGCID OBJECT-TYPE 
SYNTAX OCTET STRING 

STATUS current 

DESCRIPTION 

"The GPRS Charging ID related to this Authorization Request. 
::= { goSgppRprtGPRSChrgInf oEntry S } 



-- Notice goSgppRprtError PRC is currently not defined because all 
-- error condition handling is satisfactorily covered by using the 
-- standard COPS-PR error handling mechanism and error objects. 
— goSgppRprtError PRC should only be used for SGPP GO Application 
-- error indications if necessary. 



goSgppRprtUsageTable OBJECT-TYPE 

SYNTAX SEQUENCE OF GoSgppRprtUsageEnt ry 

PIB-ACCESS notify 
STATUS current 

DESCRIPTION 



{ goSgppReportClasses S } 



goSgppRprtUsageEntry OBJECT-TYPE 

SYNTAX goSgppRprtUsageEntry 

STATUS current 

DESCRIPTION 

"This entry represents the PEP state changes. 
FIB-INDEX { goSgppRprtUsagePrid } 
UNIQUENESS { goSgppRprtUsagelndicat ion } 
::= { goSgppRprtUsageTable 1 } 



goSgppRprtUsageEntry ::= SEQUENCE { 

goSgppRprtUsagePrid Instanceld, 
goSgppRprtUsagelndication INTEGER } 



goSgppRprtUsagePrid OBJECT-TYPE 
SYNTAX Instanceld 

STATUS current 

DESCRIPTION 

"An arbitrary integer index that uniquely identifies an 

instance of the goSgpgRprtUsage class." 

::= { goSgppRprtUsageEntry 1 } 
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go3gppRprt Us age Indication OBJECT-TYPE 
SYNTAX INTEGER { 

chngdToOkbs (1), 
chngdFromOkbs (2) } 
STATUS current 

DESCRIPTION 

"Indication of GPRS Usage change. 
ChngdToOkbs indicates changing to Okbs, 
ChngdFromOkbs indicates changing from Okbs . 
::= { goSgppRprtUsageEntry 2 } 



— Conformance Section 



go3gppCompliances 
goSgppGroups 



OBJECT IDENTIFIER ::= { go3gppConf ormance 1 } 

OBJECT IDENTIFIER ::= { go3gppConf ormance 2 



goSgppCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 

"Describes the requirements for conformance to the 
3GPP GO PIB. " 



MODULE FRAMEWORK-PIB 

MANDATORY-GROUPS { 

frwkPrcSupport Group, 
frwkDeviceldGroup } 



MODULE G03GPP-PIB — this module 
MANDATORY-GROUPS { 

go3gppAuthReqCapGroup, 

go3gppAuthReqDecCapGroup, 

go3gppAuthReqHandler Group, 

go 3gppAuthReqE vent Group, 

go3gppBindingInfoGroup, 

go3gppFlowIdGroup, 

go3gppAuthReqFailDecGroup, 

go3gppAuthReqDecGroup, 

go3gppIcidGroup, 

go3gppAuthReqDirDecGroup, 

go3gppQosGroup, 

go3gppGateDecGroup, 

go3gppGateGroup, 
-SPPI does not allow the OBJECTS clause to be empty, 
-are no objects to report in the Base Filter group, 

go 3 gppBaseF liter Group, 

go3gppIpF liter Group, 

go3gppReport Group, 

go3gppRprtGPRSChrgInfoGroup, 

go3gppRprtUsageGroup } 
::= { go3gppCompliances 1 } 



Since there 
it is commented out . 



go3gppAuthReqCapGroup OBJECT-GROUP 
OBJECTS { 

go3gppAuthReqCapBindingInf OS, 
go3gppAuthReqCapFlowIds 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB Objects that describe the 
Authorisation Request capabilities." 
::= { go3gppGroups 1 } 

go3gppAuthReqDecCapGroup OBJECT-GROUP 
OBJECTS { 
go3gppAuthReqDecCapIcids 
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STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorisation Decision capabilities." 
::= { goSgppGroups 2 } 

go3gppAuthReqHandlerGroup OBJECT-GROUP 
OBJECTS { 
goSgppAuthReqHandlerEnable, 
goSgppAuthReqHandlerBindinglnfo 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorisation request event handler." 
::= { go3gppGroups 3 } 

goSgppAuthReqEvent Group OBJECT-GROUP 
OBJECTS { 
goSgppAuthReqEvent Binding Infos 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorisation request events." 
::= { goSgppGroups 4 } 

goSgppBindinglnfoGroup OBJECT-GROUP 
OBJECTS { 
go3gppBindingInf oToken, 
goSgppBindinglnfoFlowIds, 
go3gppBindingInfoNext 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the binding information." 
::= { goSgppGroups 5 } 

go3gppFlowIdGroup OBJECT-GROUP 
OBJECTS { 
goSgppFlowIdFlowId^ 
go3gppFlowIdNext 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the flow ID." 
::= { goSgppGroups 6 } 

go3gppAuthReqFailDecGroup OBJECT-GROUP 
OBJECTS { 

goSgppAuthReqFailDecReason 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorisation failure decisions." 
::= { goSgppGroups 7 } 

goSgppAuthReqDecGroup OBJECT-GROUP 
OBJECTS { 
goSgppAuthReqDecIcids, 
goSgppAuthReqDecDirDecs 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the Authorisation decisions." 
::= { goSgppGroups 8 } 

goSgppIcidCroup OBJECT-GROUP 

OBJECTS { 
goSgppIcidValue, 
goSgppIcidNext 

} 

STATUS current 
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DESCRIPTION 

"This Group defines the PIB 

Objects that describe the ICID." 
::= { go3gppGroups 9 } 

goSgppAuthReqDirDecGroup OBJECT-GROUP 
OBJECTS { 
go3gppAuthReqDirDecDirection, 
go3gppAuthReqDirDecQos, 
goSgppAuthReqDirDecGates, 
goSgppAuthReqDirDecNext 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the authorisation decision direction." 
::= { goSgppGroups 10 } 

go3gppQosGroup OBJECT-GROUP 
OBJECTS { 
goSgppQosServiceClass, 
goSgppQosDataRateUnit, 
go3gppQosDataRate 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the QoS information." 
::= { go3gppGroups 11 } 

go3gppGateDecGroup OBJECT-GROUP 
OBJECTS { 
goSgppGateDecDirection, 
goSgppGateDecGates, 
goSgppGateDecNext 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the Gate decision." 
::= { goSgppGroups 12 } 

go3gppGateGroup OBJECT-GROUP 
OBJECTS { 
go3gppGateFilter, 
go3gppGateStatus, 
goSgppGateNext 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the gate." 
::= { goSgppGroups 13 } 

— SPPI does not allow the OBJECTS clause to be empty. Since there 
— are no objects to report in this group, it is commented out. 
— go3gppBaseFilterGroup OBJECT-GROUP 

OBJECTS { } 

STATUS current 

DESCRIPTION 
— "This Group defines the PIB Objects that describe the base filter." 

::= { goSgppGroups 14 } 

goSgppIpFilterCroup OBJECT-GROUP 
OBJECTS { 

go3gppIpFilterAddrType, 

go3gppIpFilterDstAddr, 

goSgppIpFilterDstPref ixLength, 

goSgppIpFilterSrcAddr, 

goSgppIpFilterSrcPref ixLength, 

goSgppIpFilterProtocol, 

go3gppIpFilterDstL4PortMin, 

go3gppIpFilterDstL4PortMax, 

go3gppIpFilterSrcL4PortMin, 

go3gppIpFilterSrcL4PortMax 
} 
STATUS current 
DESCRIPTION 
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"This Group defines the PIB Objects that describe the IP Filter." 
::= { go3gppGroups 14 } 

goSgppReportGroup OBJECT-GROUP 
OBJECTS { 
go3gppReportStatus, 
go 3 gppReport Details 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the PEP reports." 
::= { goSgppGroups 15 } 

go3gppRprtGPRSChrgInfoGroup OBJECT-GROUP 
OBJECTS { 
goSgppRprtCPRSChrglnfoGGSNAddr, 
go3gppRprtGPRSChrgInfoGCID 
} 
STATUS current 
DESCRIPTION 

"This Group defines the PIB 

Objects that describe the charging information." 
:;= { goSgppGroups 16 } 

goSgppRprtUsageCroup OBJECT-GROUP 
OBJECTS { 

go 3 gppRprt Us age Indication 
} 

STATUS current 
DESCRIPTION 

"This Group defines the PIB 
Objects that describe the report usage." 
::= { goSgppGroups 17 } 

END 
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Annex C (normative): 

Flow identifiers: Format definition and examples 

C.l Format of a flow identifler 

A flow identifier is expressed as a 2-tuple as follows: 
<Media component no, IP flow no.> 
where both are numbered starting from 1 . 

3 



Media component no. 


IP flow no. 



C.2 Example 1 

The second "m=" - line in the SDP information contains one RTP media specification, as follows: 

m=video 49160 RTP/AVP3I 
Two flow identifiers are assigned as shown in the table below: 



IP flow 


Port number 


Flow id. 


RTP 


49160 


<2,1> 


Associated RTCP 


49161 


<2,2> 



C.3 Example 2 

In the general case, multiple ports may be specified with a "number of ports" qualifier as follows, ref. [17]: 

m=<media> <port>/<number of ports> <transport> <fmt list> 
If the third "m="-line indicates a series of port numbers as follows: 

m=video 49170/2 RTP/AVP 31 
Four flow identifiers are assigned as shown in the table below: 



IP flow 


Port number 


Flow id. 


First RTP 


49170 


<3,1> 


First associated RTCP 


49171 


<3,2> 


Second RTP 


49172 


<3,3> 


Second associated RTCP 


49173 


<3,4> 
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Annex D (normative): 

Go interface related error code values for the PDP context 

handling 

The following error codes are used to indicate Go interface related errors from the GGSN to the UE. The error codes are 
transferred to the UE in the Protocol Configuration Options information element as defined in 3GPP TS 24.008: 

Error code No. 1 "Authorization failure of the request" 

This error code indicates that the PDP context activation/modification request is rejected because the authorizing entity 
is unable to provide an authorization decision for the binding information. 

Error code No. 2 "Missing binding information" 

This error code indicates that the PDP context activation/modification request is rejected because the binding 
information was not included in the request although required. 

Error code No. 3 "Invalid binding information" 

This error code indicates that the PDP context activation/modification request is rejected because the authorizing entity 
could not be resolved from the binding information. 
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Annex E (informative): 
Change history 
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